The IAO will ensure that the router or firewall software has been upgraded to mitigate the risk of DNS cache poisoning attack caused by a flawed PAT implementation using a predictable source port allocation method for DNS query traffic.

Overview

Finding ID	Version	Rule ID	IA Controls	Severity
V-25037	NET1970	SV-30842r1_rule	VIVM-1	High

Description
DNS cache poisoning is an attack technique that allows an attacker to introduce forged DNS information into the cache of a caching name server. There are inherent deficiencies in the DNS protocol and defects in implementations that facilitate DNS cache poisoning. Name servers vulnerable to cache poisoning attacks are due to their use of insufficiently randomized transaction IDs and UDP source ports in the DNS queries that they produce, which may allow an attacker to more easily forge DNS answers that can poison DNS caches. To exploit these vulnerabilities an attacker must be able to cause a vulnerable DNS server to perform recursive DNS queries. Therefore, DNS servers that are only authoritative, or servers where recursion is not allowed, are not affected. The DNS protocol specification includes a transaction ID field of 16 bits. If the specification is correctly implemented and the transaction ID is randomly selected with a strong random number generator, an attacker will require, on average, 32,768 attempts to successfully predict the ID. Some flawed implementations may use a smaller number of bits for this transaction ID, meaning that fewer attempts will be needed. Furthermore, there are known errors with the randomness of transaction IDs that are generated by a number of implementations. Some current implementations allocate an arbitrary source port at startup (and sometimes selected at random) and reuse this source port for all outgoing queries. With other implementations, the source port for outgoing queries is fixed at the traditional assigned DNS server UDP port number 53. Because attacks against these vulnerabilities all rely on an attacker's ability to predict, the implementation of per-query source port randomization in the server presents a practical mitigation against these attacks within the boundaries of the current protocol specification. Randomized source ports can be used to gain approximately 16 additional bits of randomness in the data that an attacker must guess. Randomizing the ports adds a significant amount of attack resiliency. Routers, firewalls, proxies, and other gateway devices that perform NAT—more specifically Port Address Translation (PAT)—often rewrite source ports in order to track connection state. A flawed implementation of a PAT device using a predictiable source port allocation method can reduce any effectiveness of source port randomization implemented by name servers and stub resolvers. Henceforth, it is imperative that the router or firewall software has been upgraded or patched to reduce an attacker’s opportunity for launching a DNS cache poisoning attack. Note: Regular NAT (allocating one public IP address for each private IP address) is not affected by this problem because it only rewrites layer 3 information and does not modify layer 4 header information of packets traversing the NAT device.

Description

DNS cache poisoning is an attack technique that allows an attacker to introduce forged DNS information into the cache of a caching name server. There are inherent deficiencies in the DNS protocol and defects in implementations that facilitate DNS cache poisoning. Name servers vulnerable to cache poisoning attacks are due to their use of insufficiently randomized transaction IDs and UDP source ports in the DNS queries that they produce, which may allow an attacker to more easily forge DNS answers that can poison DNS caches. To exploit these vulnerabilities an attacker must be able to cause a vulnerable DNS server to perform recursive DNS queries. Therefore, DNS servers that are only authoritative, or servers where recursion is not allowed, are not affected. The DNS protocol specification includes a transaction ID field of 16 bits. If the specification is correctly implemented and the transaction ID is randomly selected with a strong random number generator, an attacker will require, on average, 32,768 attempts to successfully predict the ID. Some flawed implementations may use a smaller number of bits for this transaction ID, meaning that fewer attempts will be needed. Furthermore, there are known errors with the randomness of transaction IDs that are generated by a number of implementations. Some current implementations allocate an arbitrary source port at startup (and sometimes selected at random) and reuse this source port for all outgoing queries. With other implementations, the source port for outgoing queries is fixed at the traditional assigned DNS server UDP port number 53. Because attacks against these vulnerabilities all rely on an attacker's ability to predict, the implementation of per-query source port randomization in the server presents a practical mitigation against these attacks within the boundaries of the current protocol specification. Randomized source ports can be used to gain approximately 16 additional bits of randomness in the data that an attacker must guess. Randomizing the ports adds a significant amount of attack resiliency. Routers, firewalls, proxies, and other gateway devices that perform NAT—more specifically Port Address Translation (PAT)—often rewrite source ports in order to track connection state. A flawed implementation of a PAT device using a predictiable source port allocation method can reduce any effectiveness of source port randomization implemented by name servers and stub resolvers. Henceforth, it is imperative that the router or firewall software has been upgraded or patched to reduce an attacker’s opportunity for launching a DNS cache poisoning attack. Note: Regular NAT (allocating one public IP address for each private IP address) is not affected by this problem because it only rewrites layer 3 information and does not modify layer 4 header information of packets traversing the NAT device.

STIG	Date
Perimeter Router Security Technical Implementation Guide Cisco	2015-04-06

Details

Check Text ( C-31264r1_chk )
Verify that the software implemented on the router has been updated to a release that mitigates the risk of a DNS cache poisoning attack. The vulnerable releases of IOS 12.4 will be noted with either the available fix or to contact Cisco TAC. Those releases of 12.4 that are not vulnerable will be noted. 12.4 Fixed with 12.4(18b), 12.4(19a), 12.4(19b), 12.4(21) 12.4JA Not Vulnerable 12.4JK Not Vulnerable 12.4JMA Not Vulnerable 12.4JMB Not Vulnerable 12.4JMC Not Vulnerable 12.4JX Not Vulnerable 12.4MD Fixed with 12.4(15)MD 12.4MR Fixed with 12.4(19)MR 12.4SW Vulnerable; contact TAC 12.4T Fixed with 12.4(20)T 12.4XA Fixed with 12.4(20)T 12.4XB Fixed with 12.4(2)XB10 12.4XC Vulnerable; contact TAC 12.4XD Fixed with 12.4(4)XD11 12.4XE Fixed with 12.4(20)T 12.4XF Not Vulnerable 12.4XG Not Vulnerable 12.4XJ Fixed with 12.4(20)T 12.4XK Not Vulnerable 12.4XL Fixed with 12.4(15)XL2 12.4XM Fixed with 12.4(15)XM1 12.4XN Vulnerable; contact TAC 12.4XQ Vulnerable; contact TAC 12.4XT Vulnerable; contact TAC 12.4XV Vulnerable; contact TAC 12.4XW Fixed with 12.4(11)XW8 12.4XY Fixed with 12.4(15)XY3 12.4XZ Fixed with 12.4(20)T For release prior to 12.4 go to the following URL to verify if the router or switch is vulnerable: http://www.cisco.com/en/US/products/products_security_advisory09186a00809c2168.shtml

Check Text ( C-31264r1_chk )

Verify that the software implemented on the router has been updated to a release that mitigates the risk of a DNS cache poisoning attack.

The vulnerable releases of IOS 12.4 will be noted with either the available fix or to contact Cisco TAC. Those releases of 12.4 that are not vulnerable will be noted.

12.4 Fixed with 12.4(18b), 12.4(19a), 12.4(19b), 12.4(21)
12.4JA Not Vulnerable
12.4JK Not Vulnerable
12.4JMA Not Vulnerable
12.4JMB Not Vulnerable
12.4JMC Not Vulnerable
12.4JX Not Vulnerable
12.4MD Fixed with 12.4(15)MD
12.4MR Fixed with 12.4(19)MR
12.4SW Vulnerable; contact TAC
12.4T Fixed with 12.4(20)T
12.4XA Fixed with 12.4(20)T
12.4XB Fixed with 12.4(2)XB10
12.4XC Vulnerable; contact TAC
12.4XD Fixed with 12.4(4)XD11
12.4XE Fixed with 12.4(20)T
12.4XF Not Vulnerable
12.4XG Not Vulnerable
12.4XJ Fixed with 12.4(20)T
12.4XK Not Vulnerable
12.4XL Fixed with 12.4(15)XL2
12.4XM Fixed with 12.4(15)XM1
12.4XN Vulnerable; contact TAC
12.4XQ Vulnerable; contact TAC
12.4XT Vulnerable; contact TAC
12.4XV Vulnerable; contact TAC
12.4XW Fixed with 12.4(11)XW8
12.4XY Fixed with 12.4(15)XY3
12.4XZ Fixed with 12.4(20)T

For release prior to 12.4 go to the following URL to verify if the router or switch is vulnerable:
http://www.cisco.com/en/US/products/products_security_advisory09186a00809c2168.shtml

Fix Text (F-27729r1_fix)
Update the OS to the release that mitigates the risk of a DNS cache poisoning attack